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(54) Decompressing data 

(57) In a method and apparatus for decompressing 
and communicating a predetermined amount of data in 
a client-server environment in which the server (1 0) re- 
lays communications between a client web browser (1 2) 
and at least one shared peripheral device (16), com- 
pressed data from the peripheral device (1 6) is decom- 



pressed on-the-fly, and is packaged and transmitted to 
the client web browser (1 2). Appropriate logic is provid- 
ed to ensure that the web browser receives an expected 
amount of decompressed data regardless of the amount 
of compressed data provided by the peripheral device 
(16). Moreover, logic is provided to reduce the amount 
of resources required in decompressing the data. 
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Description 

[0001] The present invention generally relates to a 
method and apparatus for decompressing data in a cli- 
ent-server environmentally and especially for decom- 
pressing scanner image data from a shared peripheral 
device and transmitting same to be viewed on a client's 
web browser. More particularly, the present invention 
concerns software/firmware which reduces the memory 
resources required in decompressing data received on- 
the-fly from a network peripheral device and transmitting 
the same to a client web browser. 
[0002] Scanning peripherals are becoming a larger 
segment of the peripheral industry. Users find such pe- 
ripherals useful as a means of input for text, graphics 
and images. Many software applications now permit 
manipulation and use of such data. 
Some peripherals combine scanning with other func- 
tions. These multifunction peripherals are popular, in 
part, because of their ability to combine multiple useful 
functions into a single device. When connected to the 
network, the peripherals are operationally connected to 
the client devices via a dedicated peripheral server, 
which includes software and firmware for allowing the 
clients to interact with the peripherals using a web 
browser. Such software and firmware are disclosed in 
commonly assigned U.S. Patent Application Serial No. 
09/163,791 filed September 30, 1998 by Kumpf et al. P 
which application is incorporated by reference herein. 
[0003] Generally, the invention disclosed in the Kumpf 
et al. application provides an interactive networked cli- 
ent-server scan method launched and actively man- 
aged through a web browser interface on a client. A 
server responds to a universal resource locator (URL) 
address identifying the server with a general purpose 
format software program that creates an interface in the 
client web browser and enables the client to interact with 
the server in initiating, altering and monitoring scan jobs 
and related data. 

[0004] The present invention is directed toward im- 
provements to the above-noted disclosure which enable 
a reduction in the amount of resources needed to de- 
compress the data generated by the peripheral. Notably, 
peripheral devices such as, for example, a scanning de- 
vice generate large amounts of data which is typically 
transmitted in a compressed format. However, a general 
purpose web browser like NETSCAPE NAVIGATOR® 
or MICROSOFT INTERNET EXPLORER® typically ex- 
pects to receive a predefined amount of decompressed 
data. Due to a variety of factors, it is difficult to predict 
the amount of data generated by a scan, even if the size 
of the image being scanned is known. Moreover, it is 
difficult to accurately predict the amount of decom- 
pressed data that will be yielded from decompressing a 
given amount of compressed data. 
[0005] Accordingly, it is an object of the present inven- 
tion to provide an improved method for decompressing 
data to be displayed on a software viewer in a client- 



server environment in which a scan server device relays 
communications over a network between at least one 
shared peripheral device which provides data in a com- 
pressed format and a web browser residing on a client 
5 device and expecting a predetermined amount (view- 
size) of decompressed data. 

[0006] It is a further object of the present invention to 
provide such a method in software or firmware residing 
on either the scan server or the client device. 

10 [0007] The present invention provides a method and 
apparatus for decompressing and communicating a pre- 
determined amount of data in a client-server environ- 
ment in which the server relays communications be- 
tween a client web browser and at least one shared pe- 

15 ripheral device. Compressed data from the peripheral 
device is decompressed on-the-f ly, and is packaged and 
transmitted to the client web browser. Appropriate logic 
is provided to ensure that the web browser receives an 
expected amount of decompressed data regardless of 

20 the amount of compressed data provided by the periph- 
eral device. Moreover, logic is provided to reduce the 
amount of resources required in decompressing the da- 
ta. 

[0008] According to one aspect of the invention, an 
25 inbound buffer storing compressed data is replenished 
each time the inbound buffer becomes depleted. 
[0009] According to another aspect of the invention, 
an outbound buffer storms decompressed data is trans- 
mitted to the web browser when the amount of decom- 
30 pressed data contained in the outbound buffer (amt- 
stored) is at least a given predetermined value. 
[0010] According to yet another aspect of the inven- 
tion, the inbound buffer storing compressed data is re- 
plenished concurrently with data decompression, such 
35 that compressed data is being stored in said inbound 
buffer as compressed data is being decompressed and 
stored in the outbound buffer. 

[001 1] In a preferred embodiment of the invention, the 
data decompression logic is embodied software/ 

40 firmware on the scan server. The scan server requests 
blocks of decompressed data from the shared peripher- 
al device, and decompresses and transmits the decom- 
pressed data on-the-fly to the client web browser. The 
server tracks the amount of data transmitted and if nec- 

45 essary initiates a padding/truncation operation to en- 
sure that the client web browser receives the expected 
amount of data. 

[0012] Other objects, features and advantages will 
become apparent upon reading the following detailed 
50 description, in conjunction with the attached drawings, 
in which: 

FIGURE 1 is an overview of network system in 
which the present method is preferably applied; and 
55 FIG. 2 is a flow chart of the data recompression 
method of the present invention. 

[001 3] Broadly stated, the present invention is direct- 
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ed to a method for reducing the amount of memory re- 
quired in decompressing data while ensuring that a pre- 
determined amount of data is decompressed. The 
present invention is realized through software, firmware, 
and hardware which provides on-the-fly decompression 
of data in a client-server environment in which a web 
browser residing on a client device specifies an expect- 
ed amount of decompressed data to be received and a 
peripheral device transmits a given amount of data 
which may or may not equal the expected amount of 
decompressed data. 

[0014] Turning now to the drawings, and particularly 
FIG. 1, the present invention is implemented in a net- 
work system including a network peripheral server 10 
such as a Hewlett-Packard JETDIRECT box. The JET- 
DIRECT box is shown and described in a Hewlett-Pack- 
ard user manual part no. 5967-2290, and is incorporated 
by reference herein. 

It should be understood, however, that the functions of 
the server 1 0 can be performed, for example, as part of 
a card that connects via a bus interface to the peripheral, 
or as part of an internal central processing unit (CPU) 
of an attached network peripheral. The server 1 0 is con- 
nected to a plurality of clients 1 2, which are typically and 
preferably personal computers (PC), via a network 14. 
The server 10 also operatively connects the clients 12 
to a peripheral device 1 6 such as a scanner, which may 
be a stand alone scan peripheral or a multifunction pe- 
ripheral (MFP) that performs various functions such as 
printing and scanning. The server 1 0 connects to a net- 
work port through a network interface unit (not shown) 
in a known manner and permits clients 12 to access the 
scanner 16. 

[0015] Using a general purpose web browser like 
NETSCAPE NAVIGATOR® or MICROSOFT INTER- 
N ET EXPLORER® it is possible to view image data pro- 
duced by the peripheral device 1 6 on the client 12. How- 
ever, one difficulty encountered in using general pur- 
pose web browsers is the need to provide the web 
browser with an expected amount of image data. Nota- 
bly, the web browser will not release the peripheral de- 
vice 16 until it receives the expected amount of data. 
Consequently, it is necessary to insure that the web 
browser will receive the expected amount of data even 
if the peripheral device 16 provides an insufficient 
amount of data. Still further, it is wasteful of system re- 
sources to decompress more data than is expected by 
the web browser. 

[0016] The method and apparatus of the present in- 
vention will now be explained with reference to the flow 
chart illustrated in FIG. 2. 

[0017] In operation, the client 12 initiates a request to 
view data such as image data generated by the periph- 
eral device 1 6 (step 1 00). The request is received by the 
server 1 0 which in turn causes the peripheral device 12 
to initiates a scanning operation. 
[0018] It should be appreciated that the server re- 
ceives data from the peripheral device 16 generally in 



real-time, and that neither the server 1 0, the web brows- 
er nor the peripheral device 16 are aware of the true 
overall size of the image data at the time the scanning 
operation is initiated. Rather, all that is actually known 

5 is the amount of decompressed data (view-size) expect- 
ed by the client web browser. Importantly, the actual 
amount of data generated by the scanning operation 
does not necessarily correlate to the view-size expected 
by the client web browser. 

10 [001 9] According to a first embodiment of the present 
invention, data decompression is handled by the server 
10. As noted, above, the server 10 does not know the 
overall size of the image data being generated by the 
peripheral device 16. Consequently, to avoid a data 

15 overflow condition in which the amount of data transmit- 
ted by a peripheral device exceeds the memory capacity 
of the server 1 0, the server 1 0 decompresses and trans- 
mits predetermined blocks of image data to the web 
browser on-the-fly. In other words, the server 10 does 

20 not attempt to decompress the entire the image data be- 
fore initiating transfer of data to the web-browser. Rath- 
er, the server 10 processes individual blocks of a pre- 
determined amount of compressed data to completion 
(decompressing the data and transmitting it to the client 

25 web browser). Depending on the resolution and size of 
the scanned image, the image data can easily total sev- 
eral megabytes (MB). Assuming that a non-trivial 
amount of data is being decompressed, the size in bytes 
of compressed data being processed on-the-fly is sig- 

30 nificantly smaller than the total image size. Notably, ac- 
cording to a preferred embodiment, the inbound buffer 
is capable of storing 512 bytes. However, one of ordi- 
nary skill in the art will appreciate that other buffer ca- 
pacities may readily be adopted as needed. The optimal 

35 size of the inbound buffer may depend on the peripheral 
being used. 

[0020] The size of the block, i.e., the amount of com- 
pressed data requested, is optimized in correspond- 
ence with the amount of bandwidth (communications 

40 speed) of the network the processing speed of the serv- 
er 1 0, and the available memory resources of the server. 
Obviously, the upper limit of the block size is limited by 
the memory capacity of the server 1 0. In any event, the 
block size of data processed by the server 10 is unre- 
lated to the overall size of the compressed image, which 
is of an unknown size. Moreover, it should be appreci- 
ated that data transport throughput and a reduction in 
memory resources are both facilitated by the on-the-fly 
data decompression processing of the present inven- 

50 tion. 

[0021] The server 10 stores compressed data in an 
inbound buffer and decompresses the data into an out- 
bound buffer. Toward this end, the server 10 allocates 
an inbound buffer for storing a given block of com- 
55 pressed data and an outbound buffer (step 1 02) for stor- 
ing decompressed data (step 102). It should be noted 
that the size of the inbound buffer need not be equal to 
the size of the outbound buffer. Rather, the inbound buff- 
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er is ideally capable of storing at least a predefined 
amount of data, which predefined amount corresponds 
to an optimum data transmission size. The optimum 
transmission size of a data packet is beyond the scope 
of the present invention. Moreover, one of ordinary skill 
in the art will appreciate the fact that the optimum trans- 
mission size of a data packet is a constant which is de- 
termined, for example, when the initial network connec- 
tion is established between the web browser and the 
server. 

[0022] After allocating the outbound buffer, the server 
10 requests the peripheral device 16 to transmit a pre- 
determined amount of compressed data (step 1 04). The 
server 10 verifies that same data was received in re- 
sponse to the request (step 106). Assuming that data 
has been received, the server 1 0 stores the data in the 
inbound buffer (step 108). As noted above, the amount 
of data requested corresponds to an optimum transfer 
size. However, depending on the image size, the 
amount of data actually received may be less than the 
amount requested. The situation in which no data is re- 
ceived will be explained below. 
[0023] Once the compressed data has been stored in 
the inbound buffer, the server commences decompres- 
sion of the data into the outbound buffer (step 1 1 0). The 
server 1 0 tracks the amount of data contained in the out- 
bound buffer and continues to decompress data into the 
outbound buffer until the amount of data reaches either 
(a) at least a remaining amount of data expected by the 
client browser (step 112), or (b) at least a predefined 
optimum transport size (step 114). 
[0024] Upon storing the predefined optimum transport 
size ("yes" branch in step 114), the outbound buffer is 
passed to the network which transmits the data to the 
web browser (step 1 1 6), whereupon allocation of a new 
outbound buffer is requested (step 118). 
[0025] After securing allocation of a new outbound 
buffer, the server verifies whether additional com- 
pressed data is stored in the inbound buffer (step 120) 
and continues decompressing data (step 110), etc. 
[0026] Periodically the server 1 0 requests the transfer 
of additional data from the peripheral device 16 ("no" 
branch in step 120). According to one aspect of the in- 
vention, the transfer of additional compressed data is 
requested each time the amount of compressed data 
contained in the inbound buffer drops below a predeter- 
mined amount. Moreover, according to a second aspect 
of the invention, the transfer of additional data occurs 
concurrently with decompression, i.e., removal, of data. 
[0027] The server 1 0 continually monitors the amount 
of data transmitted to the client 1 2 (amt-sent) as well as 
the remaining amount of data still expected by the client 
12 (amt-needed) which value corresponds to the differ- 
ence between the amount of data expected by the client 
(view-size) and the amount of data transmitted (amt- 
sent). When the remaining amount of data still expected 
by the client 12 (amt-needed) is less than or equal the 
amount of decompressed data in the outbound buffer, 



the server 10 initiates a padding/truncation step (step 
122). 

[0028] In the padding/truncation step the data con- 
tained in the outbound buffer is padded/truncated such 

5 that the amount stored in the buffer is equal to the re- 
maining amount of data still expected by the client 12 
(amt-needed). Subsequently, the outbound buffer is 
passed to the network (step 1 24) and the inbound buffer 
is deallocated, with any remaining data in the inbound 

10 buffer being discarded. 

[0029] Next, the situation in which the peripheral de- 
vice 1 6 does not transfer additional data ("no" branch in 
step 106) will be examined. Notably, on occasion, the 
view-size expected by the client device may exceed the 

15 amount of data generated by the peripheral device 16. 
As noted above, this situation is important as the client 
will not release the peripheral device 1 6 until the expect- 
ed amount of data (view-size) is received. Thus, to deal 
with this situation in which no additional compressed da- 

20 ta is available and the amount of data contained in the 
outbound buffer is less than the remaining amount of 
data expected by the client (amt-needed). the server 
again initiates the padding/truncation step (step 122). 
This time, predefined null data is added to the outbound 

25 buffer, i.e., the buffer is padded, such that the amount 
stored in the buffer is equal to the remaining amount of 
data still expected by the client (amt-needed). Subse- 
quently, the outbound buffer is passed to the network 
(step 124) and the inbound buffer is deallocated, with 

30 any remaining data in the inbound buffer being discard- 
ed. 

[0030] According to a second embodiment of the 
present invention, data decompression is handled by 
software/firmware on the client device 12. Notably, the 

35 inbound and outbound buffers and the logic for decom- 
pressing the data all reside on the client device, and 
generally the same process depicted in FIG. 2 is fol- 
lowed. However, communications between the client 
device 12 and the peripheral device 16 are relayed by 

40 the server 1 6. Specifically, the server 1 6 converts a ge- 
neric data request command issued by the client device 
into a device specific form which may be interpreted by 
the peripheral device 16. All other aspects of the inven- 
tion are similar to the above-described aspects. 

45 [0031] Notably, the client 12 processes individual 
blocks of a predetermined amount of compressed data 
to completion before requesting the transfer of addition- 
al compressed data. The client 12 stores compressed 
data in an inbound buffer and decompresses the data 

50 into an outbound buffer. Similar to the first embodiment, 
after allocating the outbound buffer, the client 12 relays 
a command to the peripheral device 16 via the server 
1 0 requesting transmission of a predetermined amount 
of compressed data (step 1 04). The server verifies that 

55 data is in fact being transferred within a given time pe- 
riod (step 1 06). Assuming that data has been received, 
the server forwards the data to the client which stores 
the data in the inbound buffer (step 108). As noted 
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above, the amount of data requested corresponds to an 
optimum transfer size. However, depending on the im- 
age size, the amount of data actually received may be 
less than the amount requested. The situation in which 
no data is received is handled in a like manner as de- 
scribed with reference to the first embodiment. 
[0032] As described above, once the compressed da- 
ta has been stored in the inbound buffer, the client 12 
commences decompression of the data into the out- 
bound buffer (step 110). The client 1 2 tracks the amount 
of data contained in the outbound buffer and continues 
to decompress data into the outbound buffer until the 
amount of data reaches either (a) at least a remaining 
amount of data expected by the browser (step 112), or 
(b) at least a predefined optimum browser transfer size 
(step 114). 

[0033] Upon storing the predefined optimum transport 
size ("yes" branch in step 114), the outbound buffer is 
passed to the browser (step 1 1 6), whereupon allocation 
of a new outbound buffer is requested (step 118). 
[0034] After securing allocation of a new outbound 
buffer, the client 12 verifies whether additional com- 
pressed data is stored in the inbound buffer (step 120) 
and continues decompressing data (step 110), etc. 
[0035] Periodically the client 1 2 relays a command to 
the server 10 requesting the transfer of additional data 
from the peripheral device 16 ("no" branch in step 120). 
According to one aspect of the invention, the transfer of 
additional compressed data is requested each time the 
amount of compressed data contained in the inbound 
buffer drops below a predetermined amount. Moreover, 
according to a second aspect of the invention, the trans- 
fer of additional data occurs concurrently with decom- 
pression, i.e., removal of data. 

[0036] The client 12 continually monitors the amount 
of data transmitted to the browser (amt-sent) as well as 
the remaining amount of data still expected by the 
browser (amt-needed), which value corresponds to the 
difference between the amount of data expected by the 
client (view-size) and the amount of data transmitted 
(amt-sent). When the remaining amount of data still ex- 
pected by the browser (amt-needed) is less than or 
equal the amount of decompressed data in the out- 
bound buffer, the client 12 initiates a padding/truncation 
step (step 122). 

[0037] In the padding/truncation step the data con- 
tained in the outbound buffer is padded/truncated such 
that the amount stored in the outbound buffer is equal 
to the remaining amount of data still expected by the 
browser (amt-needed). Subsequently, the outbound 
buffer is transferred to the browser (step 124) and the 
inbound buffer is deallocated, with any remaining data 
in the inbound buffer being discarded. 
[0038] The situation in which the peripheral device 1 6 
does not transfer additional data ("no" branch in step 
1 06) is handled in a like manner as the previous embod- 
iment. Notably, in the event that no additional com- 
pressed data is available and the amount of data con- 



tained in the outbound buffer is less than the remaining 
amount of data expected by the browser (amt-needed), 
the client 12 again initiates the padding/truncation step 
(step 122). This time, predefined null data is added to 

5 the outbound buffer, i.e., the buffer is padded, such that 
the amount stored in the outbound buffer is equal to the 
remaining amount of data still expected by the browser 
(amt-needed). Subsequently, the outbound buffer is 
passed to the browser (step 1 24) and the inbound buffer 

10 is deallocated, with any remaining data in the inbound 
buffer being discarded. 

[0039] From the foregoing description, it should be 
understood that an improved method for decompress- 
ing data in a client-server environment has been shown 

15 and described which has many desirable attributes and 
advantages. The present invention provides a fast, reli- 
able approach to decompress data generated by a pe- 
ripheral device and provide an expected amount of de- 
compressed data to a client web browser. Importantly, 

20 the present invention insures that compressed data is 
not being received faster than it can be decompressed 
and transmitted to the client web browser. Moreover, the 
present invention minimizes the amount of memory re- 
sources required to decompress the data while assuring 

25 that the data provided by the peripheral device does not 
overflow the amount of memory available. 
[0040] While various embodiments of the present in- 
vention have been shown and described, it should be 
understood that other modifications, substitutions and 

30 alternatives are apparent to one of ordinary skill in the 
art. Such modifications, substitutions and alternatives 
can be made without departing from the scope of the 
invention, which should be determined from the append- 
ed claims. 

35 [0041] Various features of the invention are set forth 
in the appended claims. 



Claims 

40 

1. A method for decompressing data to be displayed 
on a software viewer in a client-server environment 
in which a server device (10) relays communica- 
tions between at least one peripheral device (16) 

45 and at least one client device (12), wherein the soft- 
ware viewer expects a predetermined amount 
(view-size) of decompressed data, said method be- 
ing embodied in at least one of software and 
firmware executed on at least one of the client de- 

50 vice (1 2) and the server (1 0), said method compris- 
ing the steps of: 

(a) requesting a first predetermined amount of 
compressed data from the at least one periph- 

55 eral device (16); 

(b) storing said first predetermined amount of 
compressed data in an inbound buffer; 

(c) decompressing said compressed data and 
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storing decompressed data in an outbound 
buffer; 

(d) tracking the amount of data contained in the 
outbound buffer (amt-stored); 

(e) transmitting the data stored in said out- 5 
bound buffer to the software viewer; 

(f) tracking the amount of data transmitted to 
the software viewer (amt-sent); 

(g) determining a remaining amount of data ex- 
pected by the software viewer (amt-needed) as 10 

amt-needed = (view-size) - (amt-sent) 

(h) repeating steps (a)-(g) until: 15 

(1) said amount of data stored in said out- 
bound buffer (amt-stored) is at least equal 
to a remaining amount of data expected by 
the software viewer (amt-needed), or 20 

(2) no further compressed data is available 
in response to said request in step (a); and, 

(i) initiating a truncating/padding operation 
such that an amount of decompressed data 25 
equal to said amt-needed is packaged into a 
plurality of data packets and transmitted to the 
software viewer, wherein null data is selectively 
used to supplement said decompressed data 
to ensure that the software viewer receives an 30 
amount of data equal to the view-size. 



2. A method for decompressing data to be displayed 
on a software viewer according to claim 1 , wherein 
said step of requesting compressed data is execut- 
ed when an amount of compressed data stored in 
said inbound buffer is less than a second predeter- 
mined value. 

3. A method for decompressing data to be displayed 
on a software viewer according to claim 1 , wherein 
said step oftransmitting the outbound buffer is per- 
formed at least when the amount of decompressed 
data in said outbound buffer (amt-stored) is at least 
a third predetermined value. 

4. A method for decompressing data according to 
claim 1, wherein said step of requesting com- 
pressed data is executed concurrently with said da- 
ta decompressing step. 

5. A server relaying communications between at least 
one client device (12) and at least one peripheral 
device, (1 6) said server (1 0) receiving compressed 
data from the peripheral device (16) and transmit- 
ting decompressed data to the client device (12), 
where in response to a view data request from the 
client device (12), the server (10) transmits a plu- 



rality of data packets of decompressed data which 
together equal a predetermined amount of decom- 
pressed data (view-size) specified by the client de- 
vice (1 2), said server (1 0) comprising: 

at least one inbound buffer for storing com- 
pressed data; 

at least one outbound buffer for storing decom- 
pressed data; 

a processor adapted to provide: 

a data request function for requesting 
transmission of a first predetermined 
amount of compressed data from the 
shared peripheral device (16); 
a data decompression function for decom- 
pressing data stored in said at least one in- 
bound buffer and storing said decom- 
pressed data in said at least one outbound 
buffer; 

a data tracking function for tracking an 
amount of decompressed data transmitted 
to said client device (12) (amt-sent) and de- 
termining a remaining amount of data (amt- 
needed) as a difference between the view- 
size and said amt-sent; 
a data transmission function for transmit- 
ting said outbound buffer to the client de- 
vice (12); and, 

a data padding/truncation function for pad- 
ding/truncating data stored in said out- 
bound buffer. 

6. A server (10) according to claim 5, wherein said da- 
35 ta request function is initiated when an amount of 

compressed data stored in said inbound buffer is 
less than a second predetermined value. 

7. A server (1 0) according to claim 5, wherein said da- 
40 ta transmission function is initiated when an amount 

of decompressed data contained in said outbound 
buffer is at least a third predetermined value and 
when said amt-stored is equal to said amt-needed. 

45 8. A server (1 0) according to claim 5. wherein said da- 
ta request function is executed concurrently with 
said data decompression function. 

9. A server (10) according to claim 5, wherein said da- 
50 ta padding/truncation function is initiated at least 
when one of: 

no additional data is available in response to a 
request by said data request function and said 
55 am t-needed is less than said amt-stored; and, 

when said amt-stored is at least said amt-need- 
ed. 
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10. Software residing on a client device (12) for selec- 
tively requesting and decompressing data generat- 
ed by a networked peripheral device (16), the pe- 
ripheral device (1 6) being operably connected to cli- 
ent device (12) through a server (1 0), the client de- 5 
vice (12) including a web browser for initiating op- 
eration of the peripheral device (16) and specifying 

a predetermined amount of decompressed data 
(view-size), said software comprising: 

10 

at least one inbound buffer for storing com- 
pressed data; 

at least one outbound buffer for storing decom- 
pressed data; 

a data request function for requesting transmis- is 
sion of a first predetermined amount of com- 
pressed data from the networked peripheral de- 
vice (16); 

a data decompression function for decom- 
pressing data stored in said at least one in- 20 
bound buffer and storing said decompressed 
data in said at least one outbound buffer; 
a data tracking function for tracking an amount 
of decompressed data transmitted to said client 
device (12) (amt-sent) and determining a re- 25 
maining amount of data (amt-needed) as a dif- 
ference between the view-size and said amt- 
sent; 

a data transmission function for passing said 
outbound buffer to the web browser; and, 30 
a data padding/truncation function for padding 
truncating data stored in said outbound buffer. 

11. Software according to claim 10, wherein said data 
requestfunction is initiated when an amount of com- 35 
pressed data stored in said inbound buffer is less 
than a second predetermined value. 

12. Software according to claim 10, wherein said data 
transmission function is initiated when an amount 40 
of decompressed data contained in said outbound 
buffer is at least a third predetermined value and 
when said amt-stored is equal to said amt-needed. 

13. Software according to claim 10, wherein said data 45 
request function is executed concurrently with said 
data decompression function. 

14. Software according to claim 10, wherein said data 
padding/truncation function is initiated at least when so 
one of: 

no additional data is available in response to a 
request by said data request function and said 
amt-needed is less than said amt-stored; and, 55 
when said amt-stored is at least said amt-need- 
ed. 
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